(This originally appeared in the May 1995 issue of The Shareware Review, under the title "My Universe And Welcome To It". Revised 11/27/95)
When we play an adventure game, we are entering a place that's not a part of the world we live in. The game author has created his own little universe for us, with landscapes, creatures and even its own laws of nature. So I thought the above title would be perfect for a column devoted to shareware adventure games.
I've reviewed several World Builder adventures elsewhere in this issue, and examined many more besides. In doing so, I've been struck by two facts:
First, I'm amazed at the number of imaginative and intriguing concepts that have been turned into games. I've seen games based on the presidential elections; games in which the player is a cat or other animal; games about historical events or persons; and a game based on growing from a child to an adult. These were just a few of the unique and interesting game ideas I've encountered.
Secondly, I've been appalled by the way these great concepts have largely been wasted. In some cases the actual game has little to do with the topic it is supposedly based on. In other cases the authors were obviously too young and inexperienced. Programming errors, crude graphics, and a poor grasp of what makes a game worth playing have been the downfall of most.
But one of the most mistakes in WB programming comes a misunderstanding of WB's "Characters" function.
World Builder allows the programmer to create or use four basic things: Scenes, Characters, Objects and Sounds. The last of these is pretty obvious. Scenes contain the graphics representing the individual rooms or scenes of the game, plus the code that controls the action in that scene.
Objects are graphics, including invisible buttons. These can be things the player can pick up (movable objects), or things the player can simply click on (immobile objects). Immobile objects can be moved to and from scenes according to the programmer's desire, by using scene or global code. They can even be used to create simple animations.
It's the Characters that most WB programmers misunderstand, and which cause so many games to be poorly designed. Characters are controlled almost entirely by the computer, not by the programmer. They were originally intended to be used for RPG style games, where the object of the game is mainly to beat up on a bunch of monsters. But for a real adventure game, they are mostly useless due to the limited amount of control the programmer has over them.
But most new programmers don't understand this, and rely too heavily on them. As a result, we have hundreds of games out there that are basically the same thing. The player just stumbles around getting killed by various creatures. In fact, this is why I no longer recommend my own first game to anyone.
Instead of using Characters, which merely attack the player, the programmer should use Objects to simulate non-player characters, and write scene code to allow interaction with them. Having characters you can talk to, bargain with, and get information from is much more interesting than just using "Swing fist" or "fire pistol" over and over. And it makes it easier for the game author to create an engaging story.
And it's really not difficult to do. There are many different ways to program character interaction, depending on what kind of action and dialog you want. Here's just one example: Suppose you want the player to get some information from an innkeeper, but only after the player has threatened the innkeeper. Here's how the code might look:
IF{TEXT$=TALK}OR{TEXT$=INFO}OR{TEXT$=ASK}THEN
IF{INNKEEPER.1=SCENE@}THEN
IF{K1#<1}THEN
PRINT{INNKEEPER: "Sorry pal, I'm not talking. I know better than to shoot off my mouth around here."}
PRINT{"Besides, I don't like your looks, you dirty human scum!"}
EXIT
PRINT{INNKEEPER: "I don't know anything more, I swear!"}
PRINT{INNKEEPER: "Wait! Wait! I'll tell you everything, just don't hurt me!"}
PRINT{"Here's the deal: Frodo and his gang offed Gandolf and took his magic staff. I heard that it's hidden in Golem Cave, behind a large rock."}
PRINT{"That's all I know, I swear!"}
LET{K1#=1}
EXIT
PRINT{INNKEEPER: "Don't hurt me, I've told you everything I know, I swear!"}
EXIT
END
Of course, this doesn't include any other code that may be related to the scene. But in these two simple segments, you have an appropriate response every time the player tries to talk to the innkeeper or attack the innkeeper. The user variable K1 keeps track of the events, to inform the program whether or not the player has threatened the innkeeper. If desired, the innkeeper could provide new information when questioned later, by adding an additional dialogue code and updating the variable to keep track of it.
If the innkeeper never leaves the scene, you can make this code even simpler by leaving out the IF/THEN statement that checks to see if he is there.
Note also the innkeeper's insult to the player the first time the player asks for information. This is a subtle way of hinting that the player should take more serious action in order to get results.
Even when you want to have a creature that the player must conquer, it is better to use an object and code. A bit of simple code can handle the player's attempts to fight the creature using regular weapons. But most importantly, it gives you the chance to create more imaginative means of dealing with the beast. When the player has to use his head instead of the weapons menu, the confrontation becomes and interesting challenge instead of a boring annoyance.
If the player has to get past a monster that is blocking his path in some way, the monster can be tricked into eating poison or drugs. It could be lured away from the path or into a trap. The player might have to build a special weapon, requiring multiple steps. Or the player could pull, push or drop something onto the creature's head, using a rope or other tools. A potion may be required, and the player would have to collect the various ingredients. Even another creature might be involved, perhaps a parasite or predator that kills the first creature. These are just a few of the ways to make a puzzle out of defeating a monster.
I suspect that a lot of first time WB programmers give up after their first game fails to bring in the shareware bucks and accolades they expected. This is really a shame, because they have great ideas. They just need to keep working to improve their programming skills, as well as their storytelling and puzzle design skills. I want to encourage anyone who is usingWorld Builder to keep trying. We need your games!
If you'd like to see more tips on using World Builder to create better adventure games in this column, please let me know. Or if you'd like advice or assistance with a particular code, I'd be happy to help. Contact me at RayDunakin@aol.com.
